feat(localchain): add `transfer` method to LocalChainAccountKit holder #9380

0xpatrickdev · 2024-05-17T22:53:17Z

refs: #9193

Description

Adds .transfer() method to LocalChainAccountKit, working towards OrchestrationAccountI['transfer'] interface.

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

cloudflare-workers-and-pages · 2024-05-17T22:54:51Z

Deploying agoric-sdk with Cloudflare Pages

Latest commit:	`fd11145`
Status:	✅ Deploy successful!
Preview URL:	https://ec03c886.agoric-sdk.pages.dev
Branch Preview URL:	https://9193-ibc-transfer-from-lca.agoric-sdk.pages.dev

View logs

0xpatrickdev · 2024-05-22T19:00:18Z

packages/orchestration/src/exos/local-chain-account-kit.js

@@ -1,11 +1,30 @@
+// @ts-checck


We might consider renaming this - it's meant to capture the OrchestrationAccount interface implemented for a LocalChainAccount.

0xpatrickdev · 2024-05-22T19:02:35Z

packages/orchestration/src/exos/local-chain-account-kit.js

+
+          // TODO #8879 chainInfo and #9063 well-known chains
+          const { transferChannel } =
+            this.state.agoricChainInfo.connections.get(destination.chainId);


The destination: ChainAddress argument seems to assume we should be able to get channelIds from a chainId

0xpatrickdev · 2024-05-22T19:05:35Z

packages/orchestration/test/exos/local-chain-account-kit.test.ts

+      }),
+    'can create transfer msg with memo',
+  );
+  // TODO, can we intercept the bridge message to see that it has a memo?


yeah. I could add that to #9396 but I wouldn't have a case to drive it. I'd prefer to sequence that first and add the functionality here. Consider rebasing this branch on top of 9207-bridge

turadg · 2024-05-22T19:16:19Z

packages/orchestration/src/examples/stakeBld.contract.js

+      agoricChainInfo,
+    });
+  }
+
  const publicFacet = zone.exo('StakeBld', undefined, {
    makeStakeBldInvitation() {
      return zcf.makeInvitation(
        async seat => {
          const { give } = seat.getProposal();
          trace('makeStakeBldInvitation', give);
          // XXX type appears local but it's remote


this comment was for E(privateArgs.localchain).makeAccount(). best to remove it at this point

packages/orchestration/src/examples/stakeBld.contract.js

turadg · 2024-05-22T19:18:21Z

packages/orchestration/src/examples/stakeBld.contract.js

+        undefined,
+        undefined,


omission has the same effect

Suggested change

undefined,

undefined,

turadg · 2024-05-22T19:19:56Z

packages/orchestration/src/exos/local-chain-account-kit.js

+     * @param {TimerService} initState.timer
+     * @param {TimerBrand} initState.timerBrand
+     * @param {AgoricChainInfo} initState.agoricChainInfo


these aren't specific to each account kit, right? they can stay in the prepareLocalChainAccountKit closure.

Good call out, thank you

packages/orchestration/src/exos/local-chain-account-kit.js

turadg · 2024-05-22T19:22:41Z

packages/orchestration/src/exos/local-chain-account-kit.js

+              memo: opts?.memo ?? '',
+            }),
+          ]);
+          void trace('MsgTransfer result', result);


trace is sync.

Suggested change

void trace('MsgTransfer result', result);

trace('MsgTransfer result', result);

turadg · 2024-05-22T19:25:25Z

packages/orchestration/src/orchestration-api.ts

   * @returns void
   *
   * TODO document the mapping from the address to the destination chain.
   */
  transfer: (
    amount: AmountArg,
    destination: ChainAddress,
-    memo?: string,
+    opts?: IBCMsgTransferOptions,


@dtribble wants to review changes to orchestration-api. These look to me like fixups of the existing API so I wouldn't block awaitinghis review

turadg · 2024-05-22T19:27:50Z

packages/orchestration/test/examples/stake-bld.contract.test.ts

+type StartFn =
+  typeof import('@agoric/orchestration/src/examples/stakeBld.contract.js').start;
+
+test('stakeBld contract - makeAccount, deposit, withdraw', async t => {


thanks I missed this one when adding tests of the examples

turadg · 2024-05-22T19:29:44Z

packages/orchestration/test/exos/local-chain-account-kit.test.ts

+      }),
+    'can create transfer msg with memo',
+  );
+  // TODO, can we intercept the bridge message to see that it has a memo?


yeah. I could add that to #9396 but I wouldn't have a case to drive it. I'd prefer to sequence that first and add the functionality here. Consider rebasing this branch on top of 9207-bridge

turadg · 2024-05-22T19:30:43Z

packages/orchestration/test/supports.ts

+/**
+ * make a new durable baggage and zone for each vat
+ */
+export const makeBaggageAndZone = () => {


odd to have both. consider makeRootZone and make baggage from it as needed

rootZone.mapStore('publisher')

dckc

sharing thoughts so far, before going to a meeting

dckc · 2024-05-22T20:03:41Z

packages/orchestration/src/cosmos-api.ts

-    versions: { identifier: string; features: string[] }[];
-    delay_period: bigint;
-  };
+  connections: MapStore<string, IBCConnectionInfo>; // chainId or wellKnownName


mutable... hm... 🤔

What would you expect to see instead?

I'm not sure... it's an adjustment to my mental model, and I'm not sure where I might have assumed that ChainInfo is immutable. I just need to be aware of it going forward, I suppose.

(technically, this still is immutable; the value of the connections property doesn't change. it's always the same MapStore. It's just the contents of that MapStore that may change.)

One impact is the contents of connections aren't included when a CosmosChainInfo is marshaled to vstorage as part of agoricNames.

dckc · 2024-05-22T20:05:57Z

packages/orchestration/src/proposals/start-stakeBld.js

+  const timerService = await timerServiceP;
+  const timerBrand = await E(timerService).getTimerBrand();


there's an unnecessary round-trip here. I wonder whether it's worth using Promise.all() to remove it.

dckc · 2024-05-22T20:08:27Z

packages/orchestration/src/proposals/start-stakeBld.js

@@ -37,6 +46,8 @@ export const startStakeBld = async ({
    terms: {},
    privateArgs: {
      localchain: await localchain,
+      timerBrand,


It seems a little odd to pass timerBrand in separately. The contract has to rely on the caller to make sure it corresponds to timerService. Well, I suppose contracts do rely on their caller in general. So it's not a serious problem. It just feels weird.

I was looking to cache the brand since it's a remote call. I can do this in the start function instead.

dckc · 2024-05-22T20:18:53Z

packages/orchestration/src/utils/time.js

+     * @param {RelativeTimeRecord} [relativeTime] defaults to 5 minutes
+     * @returns {Promise<bigint>} Timeout timestamp in absolute nanoseconds since unix epoch
+     */
+    async getCurrentTimestamp(relativeTime) {


Let's not use the same name (getCurrentTimestamp) for a different behavior.

Perhaps getTimeoutNS()?

dckc · 2024-05-22T20:20:03Z

packages/orchestration/src/utils/time.js

+     */
+    async getCurrentTimestamp(relativeTime) {
+      const currentTime = await E(timer).getCurrentTimestamp();
+      return (


I'm a little surprised the linter didn't remove the outer parens.

dckc · 2024-05-22T20:48:53Z

packages/orchestration/src/cosmos-api.ts

@@ -29,25 +32,34 @@ export type CosmosValidatorAddress = ChainAddress & {
  addressEncoding: 'bech32';
 };

+/** Info for an IBC Connection (Chain:Chain relationship, that can contain multiple Channels) */


Suggested change

/** Info for an IBC Connection (Chain:Chain relationship, that can contain multiple Channels) */

/** Info for an IBC Connection (Chain:Chain relationship that can contain multiple Channels) */

A restrictive clause is not offset with commas. -- Restrictive Clause: Explanation and Examples

or change "that" to "which" for a non-restrictive clause:

Suggested change

/** Info for an IBC Connection (Chain:Chain relationship, that can contain multiple Channels) */

/** Info for an IBC Connection (Chain:Chain relationship, which can contain multiple Channels) */

I'm cursed with a brain that throws syntax errors on English grammar just as much as programming language grammar. :-/

Thank you - I appreciate your appreciation of grammar!

dckc · 2024-05-22T20:49:33Z

packages/orchestration/src/cosmos-api.ts

+export type IBCConnectionInfo = {
+  id: string; // e.g. connection-0
+  client_id: string; // '07-tendermint-0'
+  state: 'OPEN' | 'TRYOPEN' | 'INIT' | 'CLOSED';


I noticed that on-the-wire it's STATE_OPEN, not OPEN. Did we diverge on purpose?
orthogonal to this PR

Oversight, these should all be prefixed with STATE_, and CLOSED doesn't exist. But yes orthogonal.

Also seeing a StateSDKType type in @agoric/cosmic-proto/ibc/core/connection/v1/connection.js we can use instead. (And a similar one in /ibc/core/channel/v1/channel.js)

dckc · 2024-05-22T20:51:02Z

packages/orchestration/src/cosmos-api.ts

-    versions: { identifier: string; features: string[] }[];
-    delay_period: bigint;
-  };
+  connections: MapStore<string, IBCConnectionInfo>; // chainId or wellKnownName


when do we use chainId vs wellKnownName?

Good question, I am also wondering the same. The transfer parameters imply we should be able to get there from chainId or chainId -> wellKnownName. https://github.com/Agoric/agoric-sdk/pull/9380/files#r1610510589

I think solving this can wait for #9063

dckc · 2024-05-22T20:59:41Z

packages/orchestration/src/exos/local-chain-account-kit.js

-     * @param {import('@agoric/vats/src/localchain.js').LocalChainAccount} account
-     * @param {StorageNode} storageNode
+     * @param {object} initState
+     * @param {LocalChainAccount} initState.account


you need a LocalChainAccount to make a LocalchainAccountKit? That hurts my brain. Usually, we have either makeX or makeXKit, not both.

Agree this doesn't make sense. I suggested we rename this to something closer to OrchestrationAccountKit here:
https://github.com/Agoric/agoric-sdk/pull/9380/files#r1610504823

that makes some sense. Though will OrchestrationAccountKit be the thing for all OrchestratrionAccounts?

Another option is LocalChainAccountHolder, since we will be wrapping the LCA object in an Ownable holder for rights transfer. #9087

Though will OrchestrationAccountKit be the thing for all OrchestratrionAccounts

I'm not sure the best approach here yet, I suppose there are multiple.

I did not end up tackling this change here -seems like it can be picked up as part of #9212

dckc · 2024-05-22T21:01:25Z

packages/orchestration/src/exos/local-chain-account-kit.js

-            const result = await E(lca).executeTx([
+            const [result] = await E(lca).executeTx([


wild... was there a bug here?

The expected return for delegate() is Promise<void>, so no. In the next pass I can change the return statement of this function.

… arguments

turadg · 2024-05-23T15:45:12Z

packages/orchestration/src/cosmos-api.ts

-    versions: { identifier: string; features: string[] }[];
-    delay_period: bigint;
-  };
+  connections: MapStore<string, IBCConnectionInfo>; // chainId or wellKnownName


I think solving this can wait for #9063

turadg · 2024-05-23T15:46:31Z

packages/orchestration/src/examples/stakeAtom.contract.js

@@ -1,6 +1,8 @@
 /**
 * @file Example contract that uses orchestration
 */
+// @ts-check


the tsconfig already has checkJs: true. Please keep @ts-check out of this package so it doesn't look like it's necessary.

turadg · 2024-05-23T15:48:26Z

packages/orchestration/src/examples/stakeBld.contract.js

+  const timerBrand = await E(privateArgs.timerService).getTimerBrand();
+  const timestampHelper = makeTimestampHelper(
+    privateArgs.timerService,
+    timerBrand,
+  );


I don't see timerBrand used here. Consider,

Suggested change

const timerBrand = await E(privateArgs.timerService).getTimerBrand();

const timestampHelper = makeTimestampHelper(

privateArgs.timerService,

timerBrand,

);

const timestampHelper = await makeTimestampHelper(

privateArgs.timerService

);

Or if you expect to need timeBrand in the future,

Suggested change

const timerBrand = await E(privateArgs.timerService).getTimerBrand();

const timestampHelper = makeTimestampHelper(

privateArgs.timerService,

timerBrand,

);

const { timerBrand, timestampHelper } = await makeTimestampHelper(

privateArgs.timerService

);

I don't see timerBrand used here.

It's used in makeTimestampHelper on line 31 to build the default, right?

https://github.com/Agoric/agoric-sdk/pull/9380/files#diff-31a54bae8709455401dcdf383a90d4eddb79f4916433172da12e13075858e71cR31

makeTimestampHelper, taking the timerService, can get the brand itself. That's why my examples change it to async

turadg · 2024-05-23T15:51:48Z

packages/orchestration/src/examples/stakeBld.contract.js

+      makeAcountInvitationMaker: M.call().returns(M.promise()),
+      makeStakeBldInvitation: M.call().returns(M.promise()),


I think this way it'll validate the return value. It at least improves the documentation. We should use this style so when we start inferring TS types from the Pattern the info is there.

Suggested change

makeAcountInvitationMaker: M.call().returns(M.promise()),

makeStakeBldInvitation: M.call().returns(M.promise()),

makeAcountInvitationMaker: M.callWhen().returns(InvitationShape),

makeStakeBldInvitation: M.callWhen().returns(InvitationShape),

turadg · 2024-05-23T15:59:34Z

packages/orchestration/src/examples/stakeBld.contract.js

+            const lcaSeatKit = zcf.makeEmptySeatKit();
+            atomicTransfer(zcf, seat, lcaSeatKit.zcfSeat, give);
+            seat.exit();
+            trace('makeStakeBldInvitation tryExit lca userSeat');
+            await E(lcaSeatKit.userSeat).tryExit();
+            trace('awaiting payouts');
+            const payouts = await E(lcaSeatKit.userSeat).getPayouts();
+            trace('awaiting deposit');
+            await E(holder).deposit(await payouts.In);


I think https://github.com/Agoric/agoric-sdk/pull/9376/files#diff-54fb24f937c4f534bd01703bb857887a4a8e88ff34c8ba0948694bd69c22e375R85 may be a better pattern. cc @dckc

oh it's in master now

agoric-sdk/packages/orchestration/src/examples/swapExample.contract.js

Lines 84 to 87 in 90906b1

// deposit funds from user seat to LocalChainAccount

const payments = await withdrawFromSeat(zcf, seat, give);

await deeplyFulfilled(objectMap(payments, localAccount.deposit));

Unrelated to changes in this PR but happy to include

Ah, these lines are + but they were moved. Please if you don't mind

I went with a sightly different approach:

const { In } = await deeplyFulfilled( withdrawFromSeat(zcf, seat, give), ); await E(holder).deposit(In);

Saw this with objectMap:

ℹ RemoteError(error:captp:far-zoeTest#20001)#5: Method "In \"deposit\" method of (Account Holder holder)" called without 'this' object ℹ Error: Method "In \"deposit\" method of (Account Holder holder)" called without 'this' object

if that's the one payment then that works. The other is more general and I suspect we'll want a utility for it. Something to look into near the end as we clean up the DX

turadg · 2024-05-23T16:01:38Z

packages/orchestration/src/exos/local-chain-account-kit.js

-     * @param {import('@agoric/vats/src/localchain.js').LocalChainAccount} account
-     * @param {StorageNode} storageNode
+     * @param {object} initState
+     * @param {LocalChainAccount} initState.account


that makes some sense. Though will OrchestrationAccountKit be the thing for all OrchestratrionAccounts?

Another option is LocalChainAccountHolder, since we will be wrapping the LCA object in an Ownable holder for rights transfer. #9087

turadg · 2024-05-23T16:02:42Z

packages/orchestration/src/orchestration-api.ts

@@ -145,17 +145,17 @@ export interface OrchestrationAccountI {
  /**
   * Transfer an amount to another account, typically on another chain.
   * The promise settles when the transfer is complete.
-   * @param amount - the amount to transfer.
+   * @param amount - the amount to transfer. Can be provided as pure data using denoms or as native Amounts.


"native" is ambiguous as to whether native to Agoric or the host chain.

Suggested change

* @param amount - the amount to transfer. Can be provided as pure data using denoms or as native Amounts.

* @param amount - the amount to transfer. Can be provided as pure data using denoms or as ERTP Amounts.

👍 updating the AmountArg annotation as well

turadg · 2024-05-23T16:04:52Z

packages/orchestration/test/utils/time.test.ts

+
+  t.is(
+    await getCurrentTimestamp(
+      TimeMath.coerceRelativeTimeRecord(1n, timerBrand),


isn't this more general? why should time export the 'make' function?

turadg · 2024-05-23T16:05:23Z

packages/vats/tools/fake-bridge.js

+                    'simulated unexpected MsgTransfer packet timeout',
+                  );
+                }
+                // TODO, can we reference bank to ensure user has tokens they are transfering?


fee free to mention #9402

dckc · 2024-05-23T19:43:52Z

packages/orchestration/src/examples/stakeAtom.contract.js

@@ -99,7 +101,8 @@ export const start = async (zcf, privateArgs, baggage) => {
    {
      async makeAccount() {
        trace('makeAccount');
-        return makeAccount().then(({ account }) => account);
+        const { account } = await makeAccount();


if account is a property of the return value rather than the return value itself, the function should be called makeAccountKit, not makeAccount.

dckc · 2024-05-23T19:51:09Z

packages/orchestration/src/examples/stakeBld.contract.js

    baggage,
    makeRecorderKit,
    zcf,
+    timestampHelper,


that seems like an odd factoring. Is prepareLocalChainAccountKit supposed to work with an arbitrary implementation of this interface? Doesn't seem like it. Passing the timerService seems more straightforward.

Pass timerBrand too if awaiting it inside prepareLocalChainAccountKit would be a problem.

Agree the caller of prepareLocalChainAccountKit should only have to know about timerService. See 68c8762. I also moved getTimerBrand() back to the proposal to avoid an await during prepare.

dckc · 2024-05-23T19:52:23Z

packages/orchestration/src/examples/stakeBld.contract.js

-          );
-          trace('awaiting deposit');
-          await E(account).deposit(await payouts.In);
+  async function makeLocalAccount() {


as noted earlier:

Suggested change

async function makeLocalAccount() {

async function makeLocalAccountKit() {

cf docs on Method Naming Structure

dckc · 2024-05-23T19:58:59Z

packages/orchestration/src/exos/local-chain-account-kit.js

+              sourceChannel: transferChannel.channelId,
+              token: {
+                amount: String(amount.value),
+                // @ts-expect-error AmountArg already narrowed to DenomAmount


if you change the !matches(...) || Fail... to if (typeof amount !== 'string') throw ..., I think you won't need this override.

if ('brand' in amount) makes it happy. in, more precisely

I frequently forget to do this instead of if (amount.brand). Hopefully after writing it out now, I won't 🙂

dckc · 2024-05-23T20:01:33Z

packages/orchestration/src/exos/local-chain-account-kit.js

+          // TODO #9211 lookup denom from brand
+          !matches(amount, AmountShape) || Fail`ERTP Amounts not yet supported`;


I'm not sure what #9211 should add here. Looking up a denom for a brand in agoricNames.vbankAsset is straightforward.

Fair, really only comes into play for ICA accounts. Will still tackle this in a follow up.

dckc · 2024-05-23T20:06:09Z

packages/orchestration/src/utils/mockChainInfo.js

@@ -0,0 +1,87 @@
+/**
+ * @file Mocked Chain Info object until #8879


UNTIL is a handy notation, but I'm uneasy that there's little to stop us from closing issues without addressing them.

maybe a back-link to this PR will help a little:

vat-orchestration expose client (chain) connection info #8879

dckc · 2024-05-23T20:09:06Z

packages/orchestration/src/utils/mockChainInfo.js

+ * currently keyed by ChainId, as this is what we have
+ * available in ChainAddress to determine the correct IBCChannelID's


👍

I'm more comfortable relying on chainid since learning that they're available in-protocol (client state).

I don't think the protocol guarantees uniqueness across the interchain, so when we query for client state, we'll have to be careful to ... um... do something if we find a collision.

Ok cool. The only potential hiccup I see, if human readability of the identifier is a design constraint, is that evm chain ids are typically integers.

dckc · 2024-05-23T20:10:09Z

packages/orchestration/src/utils/mockChainInfo.js

+      ordering: Order.ORDER_UNORDERED,
+      state: IBCChannelState.STATE_OPEN,


if using these symoblic constants rather than literals was due to typing, you can address that by surrounding the whole object literal with a const type cast.

dckc · 2024-05-23T20:11:11Z

packages/orchestration/src/utils/mockChainInfo.js

+ * @param {Zone} zone
+ * @returns {Pick<CosmosChainInfo, 'connections' | 'chainId'>}
+ */
+export const prepareMockChainInfo = zone => {


This seems like odd factoring. Passing the mapstore seems more straightforward. Then you can call it addAllChainInfo or the like.

dckc · 2024-05-23T20:16:12Z

packages/orchestration/test/exos/local-chain-account-kit.test.ts

+  await t.throwsAsync(
+    () => E(account).transfer({ denom: 'ubld', value: 1n }, unknownDestination),
+    {
+      message: /not found/,


test that the bad chainId (unknown) is included in the message?

suggest: choose something more novel than unknown as the bad value

dckc · 2024-05-23T20:17:07Z

packages/orchestration/test/exos/local-chain-account-kit.test.ts

+      E(account).transfer({ denom: 'ubld', value: 10n }, destination, {
+        memo: 'hello',
+      }),
+    'can create transfer msg with memo',


I wonder about unit tests for just building the msg. you had a file of message builders in cosgov. that might be handy

Worth exploring. With jest I would reach for something like toHaveBeenCalledWith for on toBridge.

You could use sinon to spy, but be careful with shared state

And it doesn't play well with SES and durability. When we need such capability we've been making fakes and putting in that instrumentation.

dckc

I still have lots of suggestions to consider, but I suppose none of them is critical.

The implementation of the feature looks correct and the tests are sufficient.

turadg · 2024-05-23T23:56:01Z

packages/orchestration/src/examples/stakeBld.contract.js


+  // XXX is this safe to call before prepare statements are completed?


nope, it's a remote call and those can't happen in the first crank of upgrade. but we can tackle that when this gets an upgrade test

- towards `OrchestrationAccount` interface for a `LocalChainAccount` - includes `mockChainInfo` as IBCChannelIDs are needed to construct a transfer message from the `ChainAddress` parameter

0xpatrickdev force-pushed the 9193-withdraw-from-lca branch 3 times, most recently from b9e751c to da20cb6 Compare May 22, 2024 15:26

Base automatically changed from 9193-withdraw-from-lca to master May 22, 2024 15:51

0xpatrickdev force-pushed the 9193-ibc-transfer-from-lca branch from 9a89435 to ee97149 Compare May 22, 2024 18:49

0xpatrickdev marked this pull request as ready for review May 22, 2024 18:51

0xpatrickdev commented May 22, 2024

View reviewed changes

0xpatrickdev requested review from turadg and dckc May 22, 2024 19:14

turadg reviewed May 22, 2024

View reviewed changes

dckc reviewed May 22, 2024

View reviewed changes

0xpatrickdev added 3 commits May 23, 2024 09:16

refactor(orchestration): LocalchainAccountKit -> LocalChainAccountKit

142c408

fix(types): cosmos chains have more than one ibc connection

0f8eedb

feat(types): .transfer() should take timeout parameters as optional…

9c23e49

… arguments

0xpatrickdev force-pushed the 9193-ibc-transfer-from-lca branch from ee97149 to a039d56 Compare May 23, 2024 13:31

0xpatrickdev requested review from dckc and turadg May 23, 2024 15:43

turadg reviewed May 23, 2024

View reviewed changes

dckc reviewed May 23, 2024

View reviewed changes

dckc approved these changes May 23, 2024

View reviewed changes

turadg approved these changes May 23, 2024

View reviewed changes

turadg reviewed May 23, 2024

View reviewed changes

0xpatrickdev added the automerge:rebase Automatically rebase updates, then merge label May 24, 2024

0xpatrickdev force-pushed the 9193-ibc-transfer-from-lca branch from 68c8762 to 5bae30c Compare May 24, 2024 00:07

feat(localchain): add .transfer() helper to LocalChainAccount

fd11145

- towards `OrchestrationAccount` interface for a `LocalChainAccount` - includes `mockChainInfo` as IBCChannelIDs are needed to construct a transfer message from the `ChainAddress` parameter

0xpatrickdev force-pushed the 9193-ibc-transfer-from-lca branch from 5bae30c to fd11145 Compare May 24, 2024 02:31

mergify bot merged commit 96f4c73 into master May 24, 2024
63 checks passed

mergify bot deleted the 9193-ibc-transfer-from-lca branch May 24, 2024 03:46

	void trace('MsgTransfer result', result);
	trace('MsgTransfer result', result);

		const timerService = await timerServiceP;
		const timerBrand = await E(timerService).getTimerBrand();

	/** Info for an IBC Connection (Chain:Chain relationship, that can contain multiple Channels) */
	/** Info for an IBC Connection (Chain:Chain relationship that can contain multiple Channels) */

		const result = await E(lca).executeTx([
		const [result] = await E(lca).executeTx([

		makeAcountInvitationMaker: M.call().returns(M.promise()),
		makeStakeBldInvitation: M.call().returns(M.promise()),

	// deposit funds from user seat to LocalChainAccount
	const payments = await withdrawFromSeat(zcf, seat, give);
	await deeplyFulfilled(objectMap(payments, localAccount.deposit));

	* @param amount - the amount to transfer. Can be provided as pure data using denoms or as native Amounts.
	* @param amount - the amount to transfer. Can be provided as pure data using denoms or as ERTP Amounts.

	async function makeLocalAccount() {
	async function makeLocalAccountKit() {

		// TODO #9211 lookup denom from brand
		!matches(amount, AmountShape) \|\| Fail`ERTP Amounts not yet supported`;

		@@ -0,0 +1,87 @@
		/**
		* @file Mocked Chain Info object until #8879

		* currently keyed by ChainId, as this is what we have
		* available in ChainAddress to determine the correct IBCChannelID's

		ordering: Order.ORDER_UNORDERED,
		state: IBCChannelState.STATE_OPEN,


		// XXX is this safe to call before prepare statements are completed?

feat(localchain): add transfer method to LocalChainAccountKit holder #9380

feat(localchain): add transfer method to LocalChainAccountKit holder #9380

Conversation

0xpatrickdev commented May 17, 2024

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

cloudflare-workers-and-pages bot commented May 17, 2024 • edited Loading

Deploying agoric-sdk with Cloudflare Pages

Choose a reason for hiding this comment

0xpatrickdev May 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dckc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feat(localchain): add `transfer` method to LocalChainAccountKit holder #9380

feat(localchain): add `transfer` method to LocalChainAccountKit holder #9380

cloudflare-workers-and-pages bot commented May 17, 2024 •

edited

Loading

0xpatrickdev May 22, 2024 •

edited

Loading